Amazon.comのAWSデータレイク「Andes」のアーキテクチャと設計方針 #ANT311 #reinvent

AWS re:Invent 2020

#レポート

#AWS

#データレイク

春田拓海 | Takumi

2021.01.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

どうも！DA部の春田です。

本記事は、AWS re:Invent 2020のセッション動画、「ANT311: Under the hood: How Amazon uses AWS for analytics at petabyte scale」のレポート記事です。

English version is here.

以前「Andesデータレイクってどんなアーキテクチャなんだろう？」と社内で話題になったことがありましたが、ついにその構成が明らかになりました。さすがAmazon.com、AWSサービスの使いこなし度がハンパないです。

概要

Amazonのコンシューマー向けビジネスが成長し続けるにつれ、データ量やビジネスをサポートするための分析の複雑性も増してきています。このセッションでは、Amazon.comがAWSテクノロジーを使用して、どのようにセキュアで要件に応じられる環境を構築し、ペタバイト級のデータを処理・分析しているかをご紹介します。Amazon EMRやAWS Lake Formation、Amazon Redshiftらの事例とともに、Amazon.comがデータレイクと並列でスケーラブルなコンピュートエンジンを組み合わせて、どのようにデータ分析や機械学習の領域を進化させつづけているのかについて深堀していきます。また、Amazon.comが自社の規模に合わせた次世代データレイクの構築やマイグレーションにおいて直面した課題も知ることができます。

スピーカー

Karthik Kumar Odapally
- AWS Speaker
Huzefa Igatpuriwala
- Solutions Architect in Amazon Business Data Technologies, Amazon.com

Under the hood: How Amazon uses AWS for analytics at petabyte scale - AWS re:Invent 2020

内容

歴史
移行のパターン
現在のアーキテクチャ
今後の展望
さらに知りたい方へ

歴史

Amazonのビジネス全体像
- Amazonはグローバルにビジネスを分散
過去
- システムは世界最大級のOracleクラスターを保持していた
- Prime VideoやAlexa、Musicなど、複数のチームから使用されるクラスター

ビジネスの運営
- 多様なユーザーやユースケース
  - SDE、アナリスト、機械学習エンジニア
  - ユースケースのペルソナ
  - データのアクセスパターン
- 最大3.8万のアクティブデータセット、精選されたビジネスデータ
- 最大90万の日次ジョブ、最大8万のアクティブユーザー

Amazonのレガシー・データウェアハウス
ソースシステム
- Amazon DynamoDBとAmazon Aurora上にデータストア
レガシー・データウェアハウス
- 複数のサービスがOracleとRedshiftを組み合わせて動いている
- Oracleクラスターの全データを管理するシングルフリート
- SQLでハンドリングされたジョブが動くELT環境を含む
分析
- ソフトウェア・アプリケーション、レポーティングシステム、ユーザーがデータをやりとりできるインターフェース

Andes Data Lake
- Amazonが保有する、最大級のデータレイクの一つ
プロジェクトAndesのゴール: 大規模データウェアハウスとデータ処理
- Amazonのビジネスに合わせてエコシステムがスケール
- オープンシステム・アーキテクチャ: 分析で使用する技術の選択肢を提供
- AWSテクノロジーを活用し、Amazonの全ての顧客ためにそのテクノロジーを改善していく

移行のパターン

レガシー・データウェアハウスの課題
- ストレージとコンピュートが分離できない
  - 個々のコンポーネントが必要に応じてスケールできない
- メンテナンスやパッチ適応に数百時間、数ヶ月
- 費用の高いライセンス、ピーク時に合わせたハードウェアコスト
  - 一年中ピーク時のプロビジョニング・コストを払い続ける必要があった
要件
- ビジネスを止めない
  - 顧客はAmazonのサービスが24時間365日稼働していることを期待している
- 分析ソリューションの再デザイン
- 分散型のコンピュートシステム管理
  - 必要な時にコンポーネントを独立させてスケールする

移行の順序
- 膨大な技術的挑戦に2年かかった
- レガシーと新しいシステム両方を同時に走らせておく
1 メタデータとガバナンスのサービスを構築
2 OracleからS3へデータを移行するサービスを構築
- S3 = プライマリー・データストア、ランディング・ゾーン
- 古いフォーマットから新しいフォーマットへ変換
- データロードの戦略
  - データを2つのシステムに並行して存在させる
  - データ損失を起こさない
- 90万のジョブに対して、クエリ変換サービスを構築
3 一つずつレガシー・エコシステムを無効化
4 唯一のプラットフォーム、Andesデータレイクのみ保持

重要なポイント
- リーダシップのあるサポートと組織全体の賛同
- セルフサービスのツールを、削減、自動化、提供する
- マイグレーション期間中もレガシーシステムと新システムの両方を稼働させる
- エンジニアとユーザーは再トレーニングが必要となった
- 全てのステークホルダーに対して、ひたすらコミュニケーション

現在のアーキテクチャ

中央: Andes Data Lake
- S3上のOracleデータにアクセスするために、レガシー・データウェアハウスの挙動をエミュレート
- 左枠: レガシーから引き継いだシステム
  - ワークフローはほぼそのまま保持
  - S3上のOracle以外のデータも読み込めるようワークフローを拡張
- 右枠: Andes
  - S3上のデータを管理する複数のサービス群
  - 上位層にユーザーがデータセットを検索、修正できるUIを提供
  - ユーザーは一貫した方法で、データセットのバージョン複製が可能
  - 継続的にデータを下流のターゲットに反映させる
  - S3上のファイルをテーブルの用に使用できるようにする
    - データセットに対してプライマリキーを定義できるようにする
  - データセット内にMod Semantics（データの意味）を保持する
- 中央の右枠: サブスクリプションサービス
  - レガシー・システムから引き継いだオーケストレーション・サービスによって管理
  - Andes上のデータセットに変更が起こるたびに、データとメタデータをAmazonシステム中の分析環境へ反映させる
AWS Glue
- 非リレーショナルなアプローチでデータセットにアクセスする中心的存在
- ソフトウェアエンジニアリングチームがEMR経由でデータセットにアクセスできるようサポート
右: ターゲット
- Glueの同期プログラム
  - 更新されるたびにメタデータをGlue Catalogに反映させる
- Redshift Spectrum + Glue
  - データセットの同期

全マイグレーションが完了した後、レガシーのOracle環境を無効化し、徐々にバックエンドとしてS3のみ稼働。

異種（Heterogeneous）のデータソース
- Amazon Kinesis
  - Kinesis Data Streams、Data Firehose
  - リアルタイム処理とバッチ抽出
- Amazon DynamoDB Streams
  - 最初の粒度でデータを抽出
- Amazon Redshift、Amazon RDS
  - バッチ抽出
- AWS Glue + Amazon S3
  - バックエンドがS3のGlueデータセットを登録
  - CloudWatch Logsのイベントでデータを同期

Andesのメタデータサービス
- 同期の基本構造
  - データをコンピュートターゲットに書き込む
  - 到着したデータの記録をつける
  - リレーショナルデータベース上のロジックを模倣したMod Semanticsを統合
- ジョブ終了管理サービス
  - データセットの更新を取りまとめ、通知
  - Glue、Airflow、カスタムEMRオーケストレーションツールなどを使用
- マニフェスト
  - 更新されたファイルリスト
  - メタデータとMod Semanticsの記録
- アクセス管理とガバナンス
  - データセットの上に乗る抽象化層
  - 誰がどのデータセットにアクセスできるかの権限をコントロール
  - 共通の暗号鍵の管理
- ワークフロー分析のトラッキング
  - リネージを行い、上流と下流のダウンストリームを結ぶ
  - 運用のトラブルシューティング、ワークフローの探知、エンジニアリングの負担を減らす
- データフォーマット → TSVとParquet

サブスクリプション・サービス
- 大規模分析用
- 取り決め
  - ガバナンスやセキュリティ、SLAに関するメタデータ
  - 誰がどんな形でデータにアクセスしているかを可視化
  - データセットの更新頻度の宣言的定義
  - データセットの所有者はどんなサポートを提供しているか
- 同期
  - データ・メタデータの更新
  - スキーマの変更
同期プログラムのターゲット
- Amazon Redshift
  - コンピュート層の共有
  - ETL用のコンピュート
  - 高パフォーマンス、低スキルでも使用可能
- AWS Glue catalog
  - Amazon EMRベースのクライアントやAmazon Athenaなどが利用
  - ETL用のコンピュート
  - EMRのコンピュートも共有 → Spark SQLやScala
- Amazon Redshift Spectrum
  - ユーザーがデータセットにクエリできるよう、選択肢を広げておく

データ処理アーキテクチャ
- EMR上のSparkを使ってDAGのワークフローをオーケストラレーション
- 異種（Heterogeneous）のデータパイプライン
- データの集計を実施し、Redshiftにロード
- データをAWSの分析サービススタックからアクセス可能にしておく
- ScalaでSpark上で機械学習を実施する

Operational excellence
- AWSのマネージドサービスによって、ピーク時のスケーリングコストと管理オーバーヘッドを10分の1に削減
パフォーマンス効率性
- 2倍〜4倍のロードにおいて、レイテンシが40%改善
コスト最適化
- 40%から90%の運用コストを削減

今後の展望

サーバレス
- さらにマネージドサービスを活用する
最適化
- 中央集権的なのRedshiftクラスターモデルから、「各自で調達できる」Redshiftクラスターモデルへ移行
- コンピュートストレージの最適化
- コストに関する説明責任を提供
機械学習
- AndesをよりAWSの機械学習サービスと相互運用（interoperable）できるようにする
コンプライアンス
- データのレギュレーション要件ごとに自動化
Service discovery framework
- Service-to-serviceの認証を提供